2007-04-16 BJ Flak Wolf Design Doc[0]

WBQ Consulting Gamanza Design Document 2007 January Design & Scope Document for Flak Wolf Gaming Site Description: Flak Wolf (FW) is a website where gamers can trade games for other games. By using FW, gamers can quickly and easily trade games with other gamers for games of like quality. The primary focus of FW is to allow smooth, simple, and easy trading of games with realistic game tier rankings as well as provide on-line social forums for the gamer community. The ease of use of the site, access to statistics about games, tiers, waitlists, “My Games” lists, and user member feedback ratings are the key to making this site successful. This document outlines the design and requirements envisioned for successful completion of the gaming site FW. The website shall have a content management system (CMS) to drive the overall site structure, menus, hierarchies, site maps, internal search engines, security, etc. The content management of the site should be well conceived, easy to use, and allow flexibility of adding additional modules to its core architecture. It is preferred the CMS and the rest of the site be of the same technology (cfml, asp, jsp, php etc). The relative cost of creating and maintaining the site over time is related to the platforms selected so this is not trivial. The technology suggested and chosen should reflect developer communities and depth of programmer supply, technical resources, ease of transfer from environment to environment, and ease of maintenance and ability to be programmed in an OOP fashion. The look and feel of the site will largely be provided by the client with sample pages and the CMS should be able to properly reflect this look-and-feel as well as the ability to dynamically work with the tabs, menus, and hierarchies within the administration portion of the CMS. The primary sections and functions of the site are the ability for a visitor to do a quick search for games available per tier or by game name. A user should also be able to quickly locate info about a game and its related statistics so they can quickly assess what their games might be used for in a trade. The search function will depend heavily on many functions and statistical results that will be reused in many of the interfaces. A visitor can sign up quickly and easily in a simple interface that gets their basic required information. After that, a user can make a My Games list, and create a Wait List which is a list of games they would like to trade for. Users who are signed up can communicate through email with other users. The email is always masked through the site so that direct email is not automatically generated when using the site email system. This is to reduce the possibility of direct trades by passing WBQ Consulting Page 1 04/16/07 WBQ Consulting Gamanza Design Document 2007 January the system and thus thwarting the ability to have accurate statistics as well as reducing revenue. Data Validation Form entry validation should always occur client side and server side. All interfaces should include client side JavaScript functionality to help ensure good data entry practices and to make sure the user enters all required data correctly. Server side validation should occur to make sure data passed to the database is correctly formatted to avoid database errors. All errors – client side, server side, and database side – should be handled appropriately so the user can continue working and receive helpful feedback. The requirements will not specify validation for each interface, but it understood that every interface will include validation and appropriate error handling techniques to avoid data corruption, incomplete transactions, and user friendliness. The rest of this document describes in detail each section and its requirements for correct design and functionality. All the features listed thus far are further detailed below in this document. In addition to the base CMS table structures, several tables will need to house the information for the game trading system. The description is broken down into an major parts to completing this project. The core functionality of the site is required in 60 days. Requirements of this nature are marked with a red symbol. Secondary functionality is required during the next 30 days and is designated by a yellow symbol. Tertiary functionality can be scheduled for implantation with less stringent timelines and are designated by a green symbol. Requirements are listed for each step or part of the project by these degrees of necessity. The process of developing each step should be broken down into the following phases: Analyze: A needs assessment and scope document will be created for each step. This document largely fulfills this requirement. Design: Based on the scope document, a design document will be created demonstrating exactly how development is forecasted to take place. This document largely fulfills this requirement. Develop: Coding and database design take place on a localhost environment or testing server. Unit testing takes place for each piece of each step. WBQ Consulting Page 2 04/16/07 WBQ Consulting Gamanza Design Document 2007 January Implement: Once development is done, the final code is deployed and database modifications take place on the Dev/Live site. Initial testing is done at this point. Any modifications for environment take place. Evaluate (Test & Revise): After the step is implemented, it is tested by the client/other parties to assure its compliance with the original scope. Minor changes, etc may be made at this time. Significant changes to scope may require additional time for rebuilding the step. Once the step is signed-off, a final test phase may be run with limited simulated live data sets. Evaluation and testing occurs here as well. Documentation: Once the step is fully implemented live and signed-off, a documentation packet is created for delivery that includes the scope doc (this document with any updates or sections of this document for an area completed), design doc (this document or section of this document with any updates), code, table layouts, diagrams, flowcharts, changes, etc to allow for easier maintenance and modification over time. WBQ Consulting Page 3 04/16/07 WBQ Consulting Gamanza Design Document 2007 January PART ONE: CONTENT MANAGEMENT SYSTEM FW requires an easy-to-use content management system (CMS) to be used as the architectural backbone of the site. A pre-built, time-tested CMS is preferred to one built from scratch. You will not be accorded more time to build one from scratch. If you do not have a CMS, it is suggested an open source one be used and modified as necessary. PhpNuke, Php-Fusion or Php-Slash are good starting points/solutions to use for example. Final choice of desired CMS must be approved by client before any programming begins. To meet this part’s requirements, content pages will be provided by the client and should be incorporated into the site by the company completing the project as part of the CMS work. There will be approximately 20-25 pages of content initially. Additional content can be added by the client through the CMS admin interface. Requirements: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. Application variable management interface (cache, metas, titles, etc) Content management interface In-line editing interface All pages should be optimized for search engine inclusion and indexing by Google, Yahoo et, al, by use of proper resolved URL structure and proper use of meta tags on a per page basis. Content layout management Login panel with encrypted password store Page level security Group/User security Distributed content editing with page locking Dynamic menus and tabs Dynamic site map Dynamic internal search interface for internal content. Weighted menu hierarchy and visibility locations Banner-ad interface to allow Amazon/Google/Other ad partnering into CMS layout. Consistent use of style sheets Page link type management (normal, internal link (to allow multiple menu items without multiple content pages), external link, plug-in link (to internal site modules), and wrapped content) Statistics logs Page logs Pages should be robot friendly and index-able by major search bots. Flexibility to add modules as needed to architecture (see plug-in link above) Ability to adapt the shell of the CMS to allow a special quick game search bar, customized graphics, headers, footers, and menus that consistently display across all pages in the site. Audit tracking for all features of system for database entries (created by, created date, created by ip, updated by, updated date, updated by ip) Time Estimate: Analyze: 8 Design: 16 Develop: 24 Implement: 24 WBQ Consulting Page 4 04/16/07 WBQ Consulting Gamanza Design Document 2007 January Evaluate: 8 Documentation: 8 Total: 88 hrs WBQ Consulting Page 5 04/16/07 WBQ Consulting Gamanza Design Document 2007 January PART TWO: TABLE SCHEMA The tables described here will be outlined and created in MSSQL or MYSQL with relationships and links in place. A copy of the SQL to create these tables will be provided. You may need to create additional tables or modify these tables depending on other elements of design and depending on the CMS used. All tables should also have the following audit type fields in addition to the regular fields listed in the detailed schemas: • TIMESTAMP (timestamp) • DATECREATED (datetime) • DATEUPDATED (datetime) • CREATEDBY (VARCHAR 50, SHOULD BE USERNAME) • UPDATEDBY (VARCHAR 50, SHOULD BE USERNAME) • CREATEDIN (VARCHAR 150, MODULE WHERE RECORD WAS CREATED) • UPDATEDIN (VARCHAR 150, MODULE WHERE RECORD WAS UPDATED) • CREATEDBYIP (VARCHAR 200, IP/CLIENTTYPE OF CLIENT CREATING RECORD) • UPDATEDBYIP (VARCHAR 200, IP/CLIENTTYPE OF CLIENT UPDATING RECORD) The DateCreated and DateUpdated fields in particular, can be used to validate record creation times and any tables that might need a field explicitly can use these fields instead of having additional date-time fields that would essentially be identical. In addition to any tables necessary to house the CMS portion, it should be assured that the following tables be used to keep the additional data. USER: A User table, which stores the primary ID for a user profile, security question for password retrieval, old password for non-duplicating consecutive passwords, first and last name etc. USER_ADDRESS Contains multiple addresses per profile such as shipping and billing addresses types. Type lookup is stored in the LKUP control table. USER_CONTACT: Contains: emails, phones, URLS’s, faxes, etc. The type is a lookup from the LKUP table. USER_PAYMENT_METHOD: Contains user information about payment methods. 1 to many. USER_GAMES: Contains records of games a user owns and information about each game they own. 1 to many with foreign keys. USER_ABOUT: Contains entries that hold data about the user. The types are customizable through a combination of the admin interface and the LKUP admin interface. WBQ Consulting Page 6 04/16/07 WBQ Consulting Gamanza Design Document 2007 January USER_WAITLIST: Contains records of games a user is or would like to request. USER_GAMETIER_CREDITS: Contains records of credits or debits accumulated for games sent or received. GROUP: This may be part of the CMS, but users can be assigned groups so pages/plug-ins/modules/sections can have access be controlled by groups a user is in. USER_GROUP: A many to many interstitial table used to link users to groups they are in. This may be part of the CMS but should be adaptable for any portion of the site and any plug-ins or modules. OBJECT_SECURITY_ACCESS: A many to many interstitial table linking groups to objects/plug-ins/modules/pages-sections. This may be part of the CMS, but should be adaptable for general use. OBJECT_REGISTRATION: This may be part of the CMS, typically used for pages if not on the page_content table itself. If so, should allow integration with the general security to allow registration of any type of page/object/button/interface/module/plug-in to allow application of group security against records in the Object_Security_Access table. LKUP: The lookup tables can be combined into a single lookup table and controlled by a single set of methods where the virtual table name effectively becomes the LIST name. Ordinal or sequential per LIST secondary ID’s should be used instead of the table AUTOID, which becomes nominal and not used by the system. There should be an Admin interface to allow editing these tables (or a combined lookup Table). The table contains types/codes/descriptions for most other major tables in one location without creating multiple lookup tables. For example, CATNAME acts as the ‘key’ for lookup such that ATYPE would be the category for codes for an Address Type, which are contained in the CATCODE in short form (HM, [home] BL [billing], etc) and a longer description could be contained in ShortDesc (Home, Billing, etc) and Description might contain information about how or what the category and category code is or should be used (The home address type is used for shipping games, billing is….). It is preferred that a single lookup table interface and single set of methods to perform lookups for the system be adopted. If you are incapable of doing that, you probably aren’t the right person for the job. Some Initial LKUP lists needed are: • TransactionType, credit, debit, adjustment, etc. • Tier, typically numeric • PaymentType – paypal, amex, visa, mc, etc • Platform – all the platforms • UserStatus – active, unregistered (by user), banned, etc. • AddressType – billing, shipping, mailing (correspondence), etc. • ContactType – email, phone, url, cell, etc • FeedbackRatingType – Types of feedback left (positive, negative, neutral, or numeric) • ShippingMethodType – such as UPS, USPS, FedEx, used by trade history and/or preferences of user for types of shipping preferred • FeedbackNoteType – for different note types in feedback section (initial, reply, system/admin, etc) • ObjectType – used by object registration table Other or additional lookups may be noted in the individual interface requirements. WBQ Consulting Page 7 04/16/07 WBQ Consulting Gamanza Design Document 2007 January GAME: Contains all games that we know of for every platform traded in system. GAME_PLATFORM: A many to many linking games to platforms for which they are available. USER_PLATFORM: A many to many linking users to platforms for which own a system. GAME_REVIEW: A one to may that contains reviews for games. FEEDBACK_NOTE: Contains reviews for games. TRANSACTION_HISTORY: Contains any monetary transaction history for a user. Typically associated with a trade, but can also contain monthly, trial, or yearly membership fee payments. TRADE_HISTORY: Contains information for each trade occurring on the site. Additional tables may be needed as well to complete some of the advanced functionalities required. WBQ Consulting Page 8 04/16/07 WBQ Consulting Gamanza Design Document 2007 January Relationship Diagram of Tables [mock until I build real tables in MS SQL] (Not all tables needed or described are necessarily listed or shown here) Time Estimate: Analyze: 2 Design: 2 Develop (Create tables): 8 Implement: 2 Evaluate: 2 Documentation: 2 Total: 18 hrs WBQ Consulting Page 9 04/16/07 WBQ Consulting Gamanza Design Document 2007 January PART THREE: Sign-Up Interface To encourage a high sign-up and conversion rate, it is possible to access much of the basic site info through the search interface without signing up at all. Secondly, it is possible to join the site and have access to additional information and access members areas without needing to add financial (credit card/pay pal) information. Finally, a member who has entered financial information can also request and trade games. Thus, there are three types of people that will be visiting our site: • • • Visitors who don’t have accounts Limited Users who have created an account but haven’t entered a financial info. These users can add games to their lists, wish lists, use messaging, but cannot trade or use a free trial trade until they have entered in valid financial data. Full Users who have created an account and who have entered in valid financial data. Sign-up interfaces should follow same design as site and have a logical sequence common to most modern web sign-up interfaces to allow quick and easy sign up. The transition from basic setup to adding financial data should have a screen and/or info during signing of the terms of agreement that explains in detail the difference between limited and full user accounts. This same information should be available in the general help section that can be maintained through the CMS interface by the adminstrator. The limited/full account will not be fully activated until the email is verified by a click through email link that is sent to the user when they complete the first part of the account setup. After they have verified their email with the link (a unique url variable attached to their account sent in the email as part of a link), they can log in and begin to use the forums/community/advanced features available. Information required for sign-up are: 1. Basic setup: First Name Last Name User Name Password Email Shipping Address [Preferred Telephone] Birthday 2. Financial Data Setup Payment Type [PayPal, CC] Payment ‘number’ (or email for Pay Pal) Billing Address (for credit cards) SSID (for credit cards) Expiration Date (for credit cards) Name on Credit Card (for credit cards) 3. Administratively, an option to enable certain types of payments should be available so the site could effectively run on only PayPal if desired, or only CreditCards if desired. 1. NEW VISITORS WHO DON’T HAVE ACCOUNTS • Visitors can surf the site but can’t trade games and don’t have community/forum privileges: 1. Can view available games, wanted games, users by state, and all statistical info 2. Can read reviews, hints, read forum posts (can’t post) 3. Can view other users and their profiles. (can’t send messages) 4. et al… 2. USERS WHO HAVE CREATED AN ACCOUNT BUT HAVE NOT ENTERED FINANCIAL DATA • These users can create and add to their user community: WBQ Consulting Page 10 04/16/07 WBQ Consulting Gamanza Design Document 2007 January 1. Can add “friends” (xbox live, my space?), [A little vague] 2. games owned (but cannot make them available for trade) 3. About Me’s: like: music, books, quotes, vacations, and whatever else that we can think of to add in. The types could be in the lookup table, while entries could be in a f User_About table. 4. Posting privileges: Can post reviews, hints, cheats, rank games, etc 5. Can email other users -- Email addresses of users are always hidden from other users and must user the system to exchange emails to avoid outsider trading. 6. Although they can see what games are available, they cannot see what specific users have what games available to trade. When they try and “post a game for trade” or “request a game” they are taken to the sign-up to add financial data with an explanatory header message. They are notified that they will not be charged for first [three*] trades, and that we will notify them when their trial period is over [This is vague]. We will not charge anything until that point. *This section should be malleable from the Admin user interface to allow changing of the number of trades, the notification message, and whether or not a fee is charged for the trial period. Necessary user info for this level 1. Name, 2. shipping address 3. physical address 4. telephone contact 5. birthday 6. email 7. username 8. password 9. verification email returned/clicked through to site • • 3. USERS WHO HAVE CREATED AN ACCOUNT AND HAVE ENTERED FINANCIAL DATA In addition to the limited user account a full user: • Can list games to trade. • Can request games. • Can request trades directly from other user’s game lists (visible to full users only) • Can see which games people want to trade directly • Necessary user info for this level in addition to limited user account info: a. Valid payment/financial data entry* *There should be a validation process for any payment type accepted to be defined and agreed upon by client/programmer before put in place. Additional User Sign-up Requirements: Users are to be verified against current user group to avoid duplicates of users trying to create multiple accounts and/or banned users trying to create new accounts. User Data should be verified against: 1. Shipping Address 2. First Name, Last Name 3. Credit Card number (and billing address) 4. Pay Pal account email 5. Email If Any of the above criteria are the same, they will be considered as the same user and unable to complete enrollment as a full user. • [FLOW CHART AND MOCKUPS HERE] WBQ Consulting Page 11 04/16/07 WBQ Consulting Gamanza Design Document 2007 January Time Estimate: Analyze: 8 Design: 16 Develop: 60 Implement: 16 Evaluate: 4 Documentation: 8 Total: 112 WBQ Consulting Page 12 04/16/07 WBQ Consulting Gamanza Design Document 2007 January PART FOUR: Info Central (Logged-In User Start Screen) Once a user has completed at least the limited user sign up, they now are able to access additional features. In particular, they will have a central info screen that will give them links to • My Games (Games Owned interface) • Messages (Messaging interface) • Wish List (Games about which the user wants special notices/quick reference, quick convert button to Request List if a full user) • Account Info (Link to profile, password, contact, and financial info interface) • Request List [Full User Only] (Games requested for trade interface) As always, the quick search bar is always available on this screen as well as any other screen (part of the shell). [FLOW CHART AND MOCKUPS HERE] Time Estimate: Analyze: 4 Design: 8 Develop: 40 Implement: 6 Evaluate: 8 Documentation: 3 Total: 69 PART FIVE: Search Interfaces There are four areas for search and result interfaces: 1. A Quick Search, available throughout the site 2. An Advanced Search with multiple selection criteria to refine result sets 3. A Search Results screen, shared by the Quick and Advanced searches 4. ADetail screen, that displays details about a game/product chosen from the Search Results Interfaces requirements in this area are: 1. Search Bar: A quick search interface to find games by name. This quick search bar should be built in to the general interface at the header level and always accessible on practically every screen. a. The Search Bar should have a link to an Advanced Search interface. b. Clicking on the Advanced Search button/link takes user to a page with additional search options. 2. Advanced Search options should comprise: a. Keywords field (text input field, 50 max) b. The keywords field search should be able to parse each word and use it separately in the SQL query; the search should be able to use simple Booleans parsed out from keyword such as AND, OR, NOT as query linkages for each following keyword) c. Search Title &/or Description (checkboxes) WBQ Consulting Page 13 04/16/07 WBQ Consulting Gamanza Design Document 2007 January Tier (dropdown from LKUP table) Games available status (select dropdown) Platforms of game (multiselect) Zip code field (text input, numbers only, 5 digit) Proximity (select dropdown from LKUP – Options: Any, 25, 50, 100, 200, 300) There should be quick browse buttons/links/lists on this page as well, which allow a user to click on a platform, and get a paged result set (10-20 results per page). Once a browse result is produced, additional browse links (year game released for instance) and keyword within result set can further narrow the result set… (see TigerDirect.com search capacity for example). 3. Result Screen: a. In result/detail page, a link to browse interface to find games by publisher/genre/other, which would essentially be pre-built queries by clicked on criteria (see item I above for quick search/browse links). b. The detail/result page should include a zip code entry for visitors to be able enter in their zip code to generate the proximity value. c. The stats for a game should be listed as: i. Tier, [Detailed ranking value], ii. Games currently available iii. Number of users who own this game iv. Number of users who want this game v. Number of times this game has traded vi. Approximate wait time for this game (based on past history and people in line) vii. Platform of game [Only games of the same platform subcategory here can be traded in the same tier] d. Proximity of closest game (if games are available) e. “Game Includes” category [Only games of the same “Game Includes” subcategory here can be traded in the same tier] f. Make Request [Full User only] link which goes to the Confirm Request interface. Only is shown if logged in as full user and a credit/tradable game is available, otherwise, is not shown/greyed out/inactive. g. Et al… 4. Detail Screen: The detail screen of a game selected should show more information about the game in ADDITION to the above statistics which should also be displayed in more detail. a. Cover Art b. Manufacture info (normally from a feed/database copy of feed) c. All stats that we see in Result Screen. d. Number of games with manuals [do games really come with manuals?] e. Number of games with original box f. 3 reviews should be shown at bottom of this detail page, truncated to 200char. g. Links on each review to ‘Read More’ which will expand full review h. A link to full list of reviews which will be it’s own page of just reviews for this game. i. A link to ‘Review This Game’ if owned at any point in time and review not already posted by this user (it may have been traded, but if it had been owned in users list, the history of that record [marked as traded once traded out, the record should never be deleted] should allow them to review a game). j. A link to associated FORUM for this game k. A link to TIPS & TRICKS for this game l. A link to add game to WISH LIST (if not in users owned list, not shown otherwise but says ‘[You Own This] which is explained below’) m. A link to REQUEST GAME list (if credits/games for trade are available for the user for this tier of game, greyed out otherwise). If no games are currently available, this will take the user to the CONFIRM REQUEST interface to finish adding this to the Wait List. If a game is available, the same CONFIRM REQUEST interface also calls the transaction process once the user is done adding game to list. d. e. f. g. h. i. WBQ Consulting Page 14 04/16/07 WBQ Consulting Gamanza Design Document 2007 January n. A link to add the game to add to ‘I Own This’ list (if not already in owned list, otherwise, says ‘[You Own This]’ per above which is explained below). o. Clicking on a You Own This link will open up the Owned Game Detail interface pop up but first display a JS confirm warning asking, “You already own a copy of this game. Do you want to add an entry for a second copy? [OK/Cancel]”. Cancel will not allow the Owned Game Detail to pop up. [FLOW CHART AND MOCKUPS HERE] Time Estimate: Analyze: 4 Design: 8 Develop: 40 Implement: 6 Evaluate: 8 Documentation: 3 Total: 69 PART SIX: My Games Once a user has completed at least the limited user sign up, they can now add games to their games list, input what systems they own/game on. For limited and full users, the main goal is to create a complete inventory of all games owned (not just games wanted to trade) so we have an idea of what games the user likes. The easier it is to do this, the better. Interfaces related to this area are: 1. Platforms owned/games (USER_PLATFORM table) This interface should be pretty simple and short. A multiselect form should suffice. Values are stored in the USER_PLATFORM table. Games Owned 2. A search/browser interface that lets users find games and click on ‘Want It’ or ‘Own it’ links/buttons/checkboxes throughout listings. This interface should be re-useable and addressable through a quick search at top of all pages (in CMS architecture) and the result set should be essentially the same, but have some buttons visible/disabled dependent on whether someone is logged in or not. All resulting stats, etc should be available to everyone. Someone not logged in can enter a zip code in the detail page to be able to generate the proximity of a game 3. A discrete list interface of My Games, which can be edited/deleted (USER_GAME table) This interface is first clicked into from Info Central or upon completion of adding an owned game. a. A user cannot select ‘Available’ for trade for a game until they have entered financial data. A pop up/warning will take them to the financial info signup area with appropriate message explaining they must enter financial data before making a game available for trade. b. A trial member (a full user who has not shipped a game) can only receive ONE game from a direct trade process or through the Wait List until they have shipped one game. c. To add another game, the user could conduct a new search and click on the resulting I Own This link. d. In this resulting page, there should be links to: WBQ Consulting Page 15 04/16/07 WBQ Consulting Gamanza Design Document 2007 January i. View Game Detail info which will go to the Search Result Detail for that game ii. Edit Info, which will pull up the Owned Game Detail screen iii. Tips & Tricks link which will go to the specialized forum for that game showing Tips and Tricks results, iv. Forum link which will go to the general forum page for that game v. Trade Game if not marked as eligible for trade, which will put this game into the tradable pool in the system vi. Pull Game if marked as tradable, allowing the user to remove a game from trade if they have enough credits to allow this (they cannot have negative credits to remove a game from the pool). 4. Owned Game Detail: When a game is selected and the I Own This link is clicked, a screen interface appears (pop-up or replaces primary, doesn’t really matter) that has some input fields about the game that the user is adding to their owned game list (My Games): e. Rate the game 1-5 ‘stars’ (dropdown select) f. A willingness to trade status for each game of (dropdown, status kept in LKUP table) i. Yes, willing ii. Maybe for the right game iii. Never g. Did they buy the game new/used/other (dropdown, list kept in LKUP) h. A condition categorization of the game (dropdown, in LKUP table, new-in-box, excellent, good, fair, poor but works) i. Game Comes with: Each game owned must be categorized as to how it will be sent, with manual, with manual and case, with case only, or disc only [Only games of the same “Game Includes” subcategory here can be traded in the same tier] (dropdown, in LKUP table) j. A description of the game, allowing user to add comments about game condition, etc (long text field) User_Game ID FK_UID FK_GameID FK_ConditionID (Lookup) Description (ShortText, this is where users can enter info about case, manual, other condition info) Date_Tradable (datetime, the date it is made available) Tradable (int, 0=No/Removed from public search, 1=Yes, 2=Traded,) Locked (int, 0=No, 1=Yes, used during request process) DateLocked (datetime) FK_UID_Locking (user locking item) [FLOW CHART AND MOCKUPS HERE] WBQ Consulting Page 16 04/16/07 WBQ Consulting Gamanza Design Document 2007 January Time Estimate: Analyze: 4 Design: 8 Develop: 40 Implement: 6 Evaluate: 8 Documentation: 3 Total: 69 WBQ Consulting Page 17 04/16/07 WBQ Consulting Gamanza Design Document 2007 January PART SEVEN: Wish List Once a user has completed at least the limited user sign up, they can now add games to their Wish List. The Wish List is way to store a list of games the user would like to have quick access to without conducting a search each time they visit the site. Essentially, the list would resemble the Search Result Set page displaying similar information in a paged list format. If you can feed the search engine the Wish List values and take advantage of that process, that is fine. There would be a few differences however. In addition to the same result set criteria, the listing should have a link to Remove From Wish List. The wish list uses the same wait User_Waitlist table and sets the FK_GameStatus field to the value for Wishlist rather than requested. When a game is converted to requested directly from the wish list, or from anywhere else for that matter, if a user has this game already in this table, its status simply changes to the Requested value at which point, if immediately available, will kick off the confirm Trade Request process, or be queued up for a game when it becomes available. [FLOW CHART AND MOCKUPS HERE] Time Estimate: Analyze: 4 Design: 8 Develop: 40 Implement: 6 Evaluate: 8 Documentation: 3 Total: 69 PART EIGHT: Request List (Wait List) The Request List is a list of games the user would like to receive in trade. Only full users can populate the Request List. Again, this list should be very similar to the Search Result list, with same stats, and drill down links to other interfaces in addition to: • Remove (from Request List ) link/button Other Requirements: 1. A user can only add a game to the Request List if they have enough tradable games and/or credits. WBQ Consulting Page 18 04/16/07 WBQ Consulting Gamanza Design Document 2007 January 2. A user cannot have more games requested than they have games available plus the value of their credits from previous trades. 3. A user cannot remove a game from tradable status in the My Games list if it violates these conditions until they have removed a game from the Request List. 4. Tier values must be respected for all logic to allow or deny adding to Request List or removing games from tradable status in the My Games list. 5. Tier values should be looked up dynamically from the Game table, not stored on the User_Game table as tiers may change over time. 6. Credits assigned certain tiers do not mute over time even if a game changes tier as the value of the trade was such at the time traded. Thus someone trading a Tier 1 game who receives credit in the User_GameTierCredits, will always have that credit until it is used, even if that particular game traded changes tier value 3 months later when the trade credit is cashed in. However, tradable games tiers can fluctuate. The Game table is the master of a game’s current tier value. 7. The request list should display for each game in addition to other stats, etc: a. The average wait time for this game request to be fulfilled b. The number of the game in the order of being fulfilled (the game maybe 9th in line to receive this game. User_Game ID FK_UID FK_GameID FK_ConditionID (Lookup) Description (ShortText, this is where users can enter info about case, manual, other condition info) Date_Tradable (datetime, the date it is made available) Tradable (int, 0=No/Removed from public search, 1=Yes, 2=Traded,) Locked (int, 0=No, 1=Yes, used during request process) DateLocked (datetime) FK_UID_Locking (user locking item) [FLOW CHART AND MOCKUPS HERE] WBQ Consulting Page 19 04/16/07 WBQ Consulting Gamanza Design Document 2007 January Time Estimate: Analyze: 4 Design: 8 Develop: 40 Implement: 6 Evaluate: 8 Documentation: 3 Total: 69 PART NINE: About Me (My Profile) The Profile, accessible from the Info Central page, allows a user to initially see all their summary information and then to click on edit links for the details of their account. This should be laid out in a standard interface allowing access to change passwords, emails, phones, billing address, shipping address, financial information, etc. For all interfaces, validation should occur at the client browser and server side. 1. 2. Profile (User table) a. This link should go to a screen that allows a user to edit their User table info. Membership (Membership table) a. This link should go to a screen that allows a user to edit their Membership. b. This interface is laid out in more detail in Part Twenty. Billing Address (User_Address table) a. This link should allow a user to enter a Billing Address that will match up with Payment Method. b. Although the database should be strictly designed for multiple billing addresses and other address types, for now, only one Billing Address will be allowed per user. This Billing Address must match or be paired with the Payment Method. c. The Billing Address does not need to be USPS validated. d. If Pay Pal is the payment method, a Billing Address may not be necessary. Shipping Address (User_Address table) a. This link should allow a user to enter a Shipping Address at which the user wishes to receive games traded. b. The Shipping Address needs to be USPS deliverable. c. A validation of the Address should occur with the USPS web based service (free, must sign up for through USPS). d. The Shipping address should not be a PO Box, unless the PO Box can accept USPS shipments of large envelopes/small boxes (most can). A warning or help can suffice in this interface. e. [In the rare occasion that a user wants to force a non-validated address in (this can happen when a new address is created but not yet entered in USPS system, esp. for new housing, college apartments, etc), a warning screen and check off (acceptance of responsibility for accuracy of address and possible undeliverable game) needs to appear before a user can force an address not in USPS system. f. Although the database should be strictly designed for multiple shipping addresses and other address types, for now, only one Shipping Address will be allowed per user. The Billing and Shipping Address interfaces can share the same base code. About Me info (User_About table) a. As explained above, this should be a fairly customizable interface from the admin interface. When the system admin adds an entry to the LKUP list for about me’s, the 3. 4. 5. WBQ Consulting Page 20 04/16/07 WBQ Consulting Gamanza Design Document 2007 January new entry should show up automatically here with a corresponding text box or dropdown (should be a selection in the LKUP interface too) to allow the user to enter info in for this new category/info box. User info is stored in a USER_ABOUT table. b. This allows the admin to add such items over time as ‘Hair color’, ‘Interests’ ‘Hobbies’, ‘Favorite Movies’, ‘Preferred Name’ or other things as needed in the future. c. The Admin interface for this should allow naming of the Label (such as Hair Color), the length (50) , and type (alpha, datetime, or numeric). d. The About section should take the values above and dynamically display an appropriate field with correct, if general, validation on the client side. User_Payment_Method ID FK_UID FK_AddressID FK_PaymentType (int, lookup) AccountNumber (vchar, 255) NameOnAccount (vchar, 255) SecurityID (vchar, 255) EmailAssociation (varchar 255, for PayPal) User_Address ID FK_UID FK_AddressType (int, lookup) Addr1 (vchar, 255) Addr2 (vchar, 255) City (vchar, 255) Zip (vchar, 9 or 10) State (vchar, 2) [FLOW CHART AND MOCKUPS HERE] Time Estimate: Analyze: 1 Design: 1 Develop: 8 Implement: 4 WBQ Consulting Page 21 04/16/07 WBQ Consulting Gamanza Design Document 2007 January Evaluate: 4 Documentation: 1 Total: 19 hrs PART TEN: Game Review Interface The game review process is a pretty straight forward system. A user can select a game from any of the game listing locations or game detail screen and click on a link to Review the game. By clicking on this link, the user opens up a screen that allows them to rate and review the game. Who can review a game? [Any user can review a game? [Only logged, full, partial? Users can review? [Only logged in full/partial who ‘Own’ or owned the game can review the game where owned means they once had the game in their owned list but it has since marked as traded or been removed (soft deleted)? The review interface should reflect the table values. The FK_GameRating_Overall should be a look up to the lookup table of values that can be set by the administrator. Other lookups or ratable criteria may be added in time. For now, it is simply a rating and write up. The Date_Input can be replaced by the DateCreated audit field if desired (Date_Input is superfluous and only shown here to note the need for a date created field). [FLOW CHART AND MOCKUPS HERE] Time Estimate: Analyze: 1 Design: 1 Develop: 8 Implement: 4 Evaluate: 4 Documentation: 1 Total: 19 hrs WBQ Consulting Page 22 04/16/07 WBQ Consulting Gamanza Design Document 2007 January PART ELEVEN: Forums Interface, Tips & Tricks The forum should be based off an open source forum and modified as needed. No need to rebuild the wheel. There are certain minimum requirements that may impact the selection and/or modification of a forum interface: 1. Forum posts or entries need to be attachable to a given thread. 2. Forum posts or entries need to be categorized, in addition to being linked to threads, so that a particular type of post can be called a ‘Tips’ post vs. a general post. This category field should be a lookup to the Lookups table and thus modifiable in the administrator interface. 3. The forum should be searchable by type of post or entry so someone can search uniquely for Tips and Tricks posts or other categories of posts as well, 4. A link from other interfaces where games are listed should be able to auto drill into the forum system by passing some keys such as the game id, category type to search, etc, to be able to easily and quickly result in a screen populated with Tips and Tricks, or all posts, or other, for a particular game. [FLOW CHART AND MOCKUPS HERE] Time Estimate: Analyze: 1 Design: 1 Develop: 8 Implement: 4 Evaluate: 4 Documentation: 1 Total: 19 hrs WBQ Consulting Page 23 04/16/07 WBQ Consulting Gamanza Design Document 2007 January PART TWELVE: game available) Make/Confirm Request (Trade Now when When someone clicks on a link to Make a Request for an immediately available game, a Confirm Request screen appears (pop-up). When a link to Make Request is clicked and a game is available, a temporary lock should be placed on the game,long enough to allow the user to complete the transaction (5 minutes? – This variable should be abstracted out to the admin interface and settable by the admin user). The process should check just before it locks the game if the game is locked or not. If so, the pop up screen which the user is getting will let the user know that the game has just been selected for trade. Optionally, the time it was locked can be displayed if it is not yet at a Tradable status of 2. This can let the user know that it is currently being locked by another user but may become available again in (5) minutes and to check again in a few minutes. Locking fields are on User_Game table. The game will not show up as tradable during a search process (not counted in search) while it is locked. When the request is confirmed and in process ‘Traded’, the Tradable field is updated to a status of 2 and the game is no longer available. Billing When a requestor is shipped a game during the trading process, they will be billed or debited a trade credit. The TradeCredits field on the User table tracks how many credits for trade a user has. If when a user trades (the requestor) a game and they do not have positive credits, the monetary based single transaction billing transaction process occurs. (See the Biling Engine Process). If the transaction involved simply debiting the TradeCredits, a TransactionHistory record is still entered and associated with the trade (FK_TID) but the transaction type is of an internal nature (lookup table). Rather than having the normal monetary and monetary method values, the payment is effected by an internal debit. Such would be noted on the transaction description. This is explained in more detail in the Billing Engine process. [We need to check on the details/peculiarities of the PayPal subscription process and if it allows variable billing] Shipping label (See shipping process, [data part Trade table, add more fields depending on what we find out from USPS, etc.?] [FLOW CHART AND MOCKUPS HERE] WBQ Consulting Page 24 04/16/07 WBQ Consulting Gamanza Design Document 2007 January Time Estimate: Analyze: 1 Design: 1 Develop: 8 Implement: 4 Evaluate: 4 Documentation: 1 Total: 19 hrs PART THIRTEEN: Process Wait List Process & Automatic Wait List When a user has requested a game that is not immediately available, rather than kicking off the confirm request process, it goes into the User_Waitlist table and awaits the game requested to proceed with a trade (See Wait List / Request List above). When a game is marked as tradable by a user this process should run across the system and check for games requests that match this game listing. Obviously, the game_id and the tier should match. Beyond that, multiple matches should be paired by priority. Priority should consist of: • Date_Requested (datetime) • [User Rating as a tie breaker when DateTime are identical or within [10minutes, 1 day] of each other.] • A verification of tradeable credits/games up for trade of like Tier value. Once a match is found and verified as the highest priority candidate, the Confirm request process is automatically run through with default values to affirm the process. The rest of the process kicks off as in the Confirm/Make request process except instead of pop-ups for each of the screens such as shipping and entering detail information, an email to the user is generated with links to the same interfaces, such that, if a user placed a game for trade and the process then found it a request, the user would be notified by email in the message center and their associated external email that their game has been requested and marked as in the trading process (in the User_Game table) with a link to the interface to the shipping interface, to print out a label, and mark the game as shipped un the User_Game table, and insert a DateGameShipped datetime value in the TradeHistory table. If the user is still currently online and has not logged out before the transaction has occurred, they system should spawn a pop up on the load of their next page that informs them the game has been traded and they can proceed to enter shipping info/print out a shipping label. User_Game ID FK_UID FK_GameID FK_ConditionID (Lookup) Description (ShortText, this is where users can enter info about case, manual, other condition info) Date_Tradable (datetime, the date it is made available) Tradable (int, lookup, 0=No/Removed from public search, 1=Yes, 2=In Process, 3=Shipped, 4=Received, 5=TradeComplete,) Locked (int, 0=No, 1=Yes, used during request process) DateLocked (datetime) Deleted (0=No, defaultm 1=Yes, in the event a game is REMOVED from owned list, but not traded, a soft delete field shows that the user owned the game but does not currently. FK_UID_Locking (user locking item) WBQ Consulting Page 25 04/16/07 WBQ Consulting Gamanza Design Document 2007 January [FLOW CHART AND MOCKUPS HERE] Time Estimate: Analyze: 1 Design: 1 Develop: 8 Implement: 4 Evaluate: 4 Documentation: 1 Total: 19 hrs PART FOURTEEN: 1. Feedback process a. When e. Feedback Interface [FLOW CHART AND MOCKUPS HERE] Time Estimate: Analyze: 1 Design: 1 Develop: 8 WBQ Consulting Page 26 04/16/07 WBQ Consulting Gamanza Design Document 2007 January Implement: 4 Evaluate: 4 Documentation: 1 Total: 19 hrs WBQ Consulting Page 27 04/16/07 WBQ Consulting Gamanza Design Document 2007 January PART FIFTEEN: 1. Trade History About me info (USER_ABOUT table) a. As explained above, this should be a fairly customizable interface from the admin interface. When the client admin adds an entry to the LKUP list for about me’s, the new entry should show up automatically here with a corresponding text box or dropdown (should be a selection in the LKUP interface too) to allow the user to enter info in for this new category/info box. User info is stored in a USER_ABOUT table. [FLOW CHART AND MOCKUPS HERE] Time Estimate: Analyze: 1 Design: 1 Develop: 8 Implement: 4 Evaluate: 4 Documentation: 1 Total: 19 hrs WBQ Consulting Page 28 04/16/07 WBQ Consulting Gamanza Design Document 2007 January PART SIXTEEN: 2. Transaction History (Billing History) About me info (USER_ABOUT table) b. As explained above, this should be a fairly customizable interface from the admin interface. When the client admin adds an entry to the LKUP list for about me’s, the new entry should show up automatically here with a corresponding text box or dropdown (should be a selection in the LKUP interface too) to allow the user to enter info in for this new category/info box. User info is stored in a USER_ABOUT table. [FLOW CHART AND MOCKUPS HERE] Time Estimate: Analyze: 1 Design: 1 Develop: 8 Implement: 4 Evaluate: 4 Documentation: 1 Total: 19 hrs WBQ Consulting Page 29 04/16/07 WBQ Consulting Gamanza Design Document 2007 January PART SEVENTEEN: 1. MESSAGING/EMAIL INTERFACE About me info (USER_ABOUT table) a. As explained above, this should be a fairly customizable interface from the admin interface. When the client admin adds an entry to the LKUP list for about me’s, the new entry should show up automatically here with a corresponding text box or dropdown (should be a selection in the LKUP interface too) to allow the user to enter info in for this new category/info box. User info is stored in a USER_ABOUT table. [FLOW CHART AND MOCKUPS HERE] Time Estimate: Analyze: 1 Design: 1 Develop: 8 Implement: 4 Evaluate: 4 Documentation: 1 Total: 19 hrs WBQ Consulting Page 30 04/16/07 WBQ Consulting Gamanza Design Document 2007 January PART EIGHTEEN: 1. GAME RANKING SYSTEM About me info (USER_ABOUT table) a. As explained above, this should be a fairly customizable interface from the admin interface. When the client admin adds an entry to the LKUP list for about me’s, the new entry should show up automatically here with a corresponding text box or dropdown (should be a selection in the LKUP interface too) to allow the user to enter info in for this new category/info box. User info is stored in a USER_ABOUT table. [FLOW CHART AND MOCKUPS HERE] Time Estimate: Analyze: 1 Design: 1 Develop: 8 Implement: 4 Evaluate: 4 Documentation: 1 Total: 19 hrs PART NINETEEN: GAME ADMIN INTERFACE The game admin interface is primarily an overlay of the GAME table (see diagram). The interface should include the following elements: A search screen A results screen A detail view screen A detail edit screen (may be combined with view screen if done well) An Add New Game link/button should be available at the POE for this admin interface. The editable features of a game should essentially reflect the table values for a given game. The Seed dropdown (yes/no) should be stored as a 1/0. This value indicates to the search/results interfaces to always show at least one game available when this value is a 1 and the date now() falls between the Seed_StartDate and Seed_EndDate values. This allows the proprietors to seed games by buying certain hard to find games and seed them into the system without purchasing them in advance. WBQ Consulting Page 31 04/16/07 WBQ Consulting Gamanza Design Document 2007 January Game ID (auto, int) Title (varchar 255) GameDescription (longtext) GameImage_1 (binary stored in db, or varchar with link) GameImage_2 (binary stored in db, or varchar with link) GameImage_3 (binary stored in db, or varchar with link) GameImage_4 (binary stored in db, or varchar with link) GameFeed_1 (tba, feed link to game maker RSS or XML feed) GameFeed_2 (tba if nec., feed link to game maker RSS or XML feed) GameFeed_3 (tba if nec., feed link to game maker RSS or XML feed) GameFeed_4 (tba if nec., feed link to game maker RSS or XML feed) Price_MSRP (float) Price_Street (float) Date_Released (date) FK_GID_FollowUp (Foreign Key in this table to Game ID that is follow-up version) FK_TierType (Lookup) Seed (Int, whether or not the game is in seed mode) Seed_StartDate (Date seeding starts) Seed_EndDate (Date seeding ends) [FLOW CHART AND MOCKUPS HERE] Time Estimate: Analyze: 1 Design: 1 Develop: 8 Implement: 4 Evaluate: 4 Documentation: 1 Total: 19 hrs WBQ Consulting Page 32 04/16/07 WBQ Consulting Gamanza Design Document 2007 January PART TWENTY: PRICING TERMS, MEMBERSHIP OPTIONS See notes from 1-16 meeting with BJ PART TWENTYONE: INTERFACE SHIPPING PROCESS/USPS PART TWENTYTWO: BILLING ENGINE/ PROCESS (PayPal) Everyday, a scheduled billing engine/payment notification engine will roll across the V_SUBCATS table and determine when auto-payments should be made and when notifications should be made for payment. If due date and auto renew match criteria and all statii are good, then find all other matching subscriptions for this profile with same billing date and auto-renew to summarize pricing, create payment history in session, transact the purchase, commit payment history, update subscription(s)’ valid dates, and send receipt email with transaction details to vendor. Error handling should include rebilling tries for 3 days and sending out email each day to vendor to encourage them to check payment profile information and the nature of the error (expired, invalid cc num, etc). Error notes should be logged in DB in appropriate fields already designed. Disable subscription after 3rd failure to renew. ElseIf not auto-renew, send notification to renew at 7, 3, 1, 0, -1, -3 day increments. Disable subscription at -1 day. If the vendor is a realtor, it should also have a sub-process that will roll across the V_MLS table and roll up billing for any/all MLS listings the realtor has attached to his/her profile. Additionally, this engine should also handle the daily process of notifying vendors on wait lists of newly available sub-categories and create a separate email for such when applicable. Requirements: 1. 2. The flow should follow the description of logic stated above. At each point in the flow, error handling should be in place to deal with faults. Time Estimate: Analyze: Design: Develop: Implement: Evaluate: Documentation: Total: WBQ Consulting Page 33 04/16/07 WBQ Consulting Gamanza Design Document 2007 January PART TWENTYTHREE: OTHER ADMIN INTERACES… WBQ Consulting Page 34 04/16/07 WBQ Consulting Gamanza Design Document 2007 January WBQ Consulting Page 35 04/16/07 WBQ Consulting Gamanza Design Document 2007 January SUMMARY: Please summarize your estimates here: Time Estimate: Analyze: Design: Develop: Implement: Evaluate: Documentation: Total: Please add comments or other conditions here. WBQ Consulting Page 36 04/16/07 WBQ Consulting Gamanza Design Document 2007 January TIMELINE: (GANT CHART WITH PART/TIMELINE) Time Estimate: Analyze: Design: Develop: Implement: Evaluate: Documentation: Total: Please add comments or other conditions here. WBQ Consulting Page 37 04/16/07